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MEMORANDUM FOR MR. J. D. HILL 


E 
SUBJ: Annex D to the Shuttle Mission Operations Task Force : 
Evaluation Report (SMOTE) . e 


l.. The attached document, subject as above, details and 
substantiates NRP requirements. It is being made avail- 
able at this time to meet the immediate needs of DOD and 
the Air Staff to baseline NRP requirements to the PD~42/0MB 
STS Mission Operations Study and justification for the USAF 
Mission Element Need Statement (MENS) defining the DOD 
Shuttle mission operations requirements. 


‘2. %xIt should be recognized that this is a preliminary docu- 
ment and used accordingly. The final "NRP Requirements For 
Space Transportation System Flight Operations," is still in 
preparation and will be submitted for DNRO approval and 
dissemination on 22 June 1979. This should provide ample 
time for accomplishing any additional staffing that may be 
necessary in meeting the OMB deadline 1 August 1979. 
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DOCUMENT HANDLING INSTRUCTIONS 
AND SECURITY ‘MARKING 


This document is being made available at this time to 
meet the immediate needs to DOD and the Air Staff to 
baseline NRP requirements to the PD-42/0MB STS Mission 
Operations Study and justification for the USAF 
Mission Element Need Statement (MENS) defining the DOD 
Shuttle mission operations requirements. 


It should be recognized that this is a preliminary 
document and used accordingly. The final "NRP Require- 
ments for Space Transportation System Flight Opera- 
tions," is still.in preparation and will be submitted. 
for DNRO approval and dissemination. on 22 June 1979. 
This should provide ample time for accomplishing any 
additional staffing that may be necessary in meeting. 
the OMB deadline of 1 August 1979. 


Because of the varied uses, pages are marked according 
to content -- Unclassified through total code word 
BYEMAN. ‘ 
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PREFACE 


In response to the direction set forth in National 
Space Policy (PD/NSC-42) to review and formulate a 
strategy for the utilization of the Space Transportation 
System (STS), this document sets forth the requirements 
of the National Reconnaissance Program to employ the 
STS in supporting its foreign intelligence collection 
operations. Guiding this review is the explicit recog- 
nition that a significant percentage of the United 
States' capability to conduct foreign intelligence is 
via space systems, and that in the mid-1980s the STS 
will become the nation's sole means of gaining access 
to the space media from which foreign intelligence 
activities are conducted. . 


The National Reconnaissance Office has conducted 
this review of workload, security and control require-. 
ments from the 1980s to the mid-1990s to assure that 
appropriate STS mission planning and operations resources 
will be available for National Reconnaissance Program 


operations. 
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In the mid-1980s, the space Shuttle will become the sole 
means of gaining access to space from which a major portion 
of this nation's foreign intelligence activities are conducted. 
This report sets forth the mission management control required 
by the National Reconnaissance Program (NRP) to employ the 
Shuttle for these activities, presents the NRP's potential 
Shuttle workload, and specifies the security framework needed 
for flight planning, readiness and control. 


Two employment concepts characterize the range of options 
for using the Shuttle for NRP missions: (1) use the Shuttle 
analogous to expendable launch vehicles for payload delivery 
only and/or (2) fully exploit the features of the Shuttle, 
particularly the role of man, in the conduct of space opera~ 
tions. The "payload delivery" employment concept is representa- 
tive of pre-1975 NRO policy whereby the principal concern was 
the transitioning of NRP payloads to the Shuttle. As Shuttle 
development milestones were passed, a restructured NRO policy 
evolved from recognition that continuation of a “payload 
delivery" employment concept was no longer a necessary or pre- 
ferred strategy from both (a) a cost efficiency viewpoint if 
the United States is to extract maximum benefit from the 
sixteen billion dollars invested in the Shuttle program; and 
(b) an effectiveness viewpoint recognizing that the nation is 
increasing its utilization of the space medium and therefore 
is becoming more dependent upon space systems as key instru- 
ments of national security. The updated NRO policy which has 
been in effect since 1978 has as a goal full exploitation of 
tha Shuttle __Nacr space systems (e.g. 

















now in various stages of development reflect 








a commitment toward this goal. Greater consideration is being 
given to responding to crises, unanticipated events, contingency 
Operations, and R&D missions. 


The payload/Shuttle interfaces for this employment concept 
are, by necessity, much more complex than “payload delivery." 
For example, Mission Controllers and Payload Specialists must 
not only be familiar with the Orbiter but must also be thoroughly 
proficient with the payload.- Missions will have to be planned, 
coordinated, rehearsed and conducted as an integrated operation. 
Traditional booster operations, and other activities associated 
with the booster, can no longer be decoupled from payload opera- 
tions as the payload/ilaunch vehicle interactions become more 
dynamic and increase in number and complexity. 
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By contrast, the controlled mode concept of mission control, 
which evolved in 1977, had as one of its key assumptions the 
"payload delivery" employment concept only, whereby interfaces 
between the Shuttle and the payload were kept simple, and on- 
orbit operations completely decoupled. It also recognized 
there was not sufficient time, facilities nor expertise avail- 
able within the DOD to develop a capability to control NRO/DOD 
Shuttle flights upon which,NRO/DOD payloads were manifested. 


DATO YER RL TER aS 2 RNAS RSE 1 


; 


However, the issue of statutory responsibilities for mission 
control remains. The controlled mode imposes compromises on the 
time-tested procedures for conducting NRO space operations. The 
key to the NRO's high success rate has been its ability to exer- 
cise control over all aspects of the mission including planning, 
rehearsals, simulations of anomalies, launch preparation, launch 
and recovery operations so that there is unity of purpose, coordi- 
nated action by all mission participants, and strict adherence to ; 
operations security procedures. 





As the NRO moves toward the goal of "full exploitation," 
mission control problems will be exacerbated relative to the 
controlled mode way of operating. Missions become more dynamic 
as the Orbiter assumes a role as a base station for construction 
or military operations, as a spacecraft mission platform, as a 
responsive vehicle for contingency and crisis support, and a 
flexible means for coping with unscheduled or unforeseen events. 
Clear boundaries between the payload and the Orbiter diffuse as 
additional and more complex on-orbit functions enter the work- 
load. This diffusion givesrise to the need to plan, simulate 
and conduct the mission as an integrated operation. The 
control infrastructure will also be impacted by the volute 
of the workload and the need to coordinate and schedule all 
NRO mission activities in response to national requiréments. 
Positive control and authority to interrupt other activities 
becomes an essential element so that the Shuttle system can be 
as responsive as possible. 


Thus, mission control for an STS employment concépt 
directed toward full exploitation encompasses all facets of 
Shuttle flight planning and operations... For NRP missions 
this requires authority and responsibility to: 


a. Approve, arrange for and supervise STS flight 
preparations to include payload and flight schedules, 
mission planning, preflight profiles, rehearsals, simulations 
and training 
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b. Exercise supervision over prelaunch and on-orbit 
operations 


c. Approve key manpower positions affecting intelli- 
gence and operations, as well as personnel selection and assign- 


ment authority 


d. Approve, exercise and control contingency opera- 
tions to include preflight and prelaunch operational and 
readiness rehearsals 


e. Establish security requirements for all intelli- 
gence related space operations 


An analysis of NRP workload for the STS was made for the 
FY-81 to FY-95 time period. The analysis addressed not only pay- 
load delivery missions included in the current DOD space mission 
model but for the first time addressed STS exploitation oppor- 
tunities =- l.e., contingency support, retrieval, 
repair and service, On-Orbit construction, and a menu of R&D 
program opportunities ranging from component tests through proto- 
type demonstration systems. Specific conclusions are: 














a. The NRP workload is not properly estimated in the 
current mission model, which is essentially payload-delivery 
oriented. 


_b. ing to the latest programmatic and schedule 
informatio NRP payload delivery and are 


scheduled p ¥-85: 









































; c. Contingency workload in support of crisis operations 

is significant and probably understated because the full potential 
exploitation of the STS is not yet understood. Maintaining readi- 
ness for such missions represents additional, workload. 


: d. Projected NRP R&D workload includes a few dedicated 
flights, but most are ride-share candidates. R&D workload will 
be superimposed upon the scheduled NRP and DOD workload. 


_, @-+ Because of lack of experience, requirements for repair, 
servicing and retrieval are probably understated by the programs 
surveyed. 


: ie On~orbit construction when it occurs significantly 
impacts on-orbit time requirements. 
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Workload estimates in this review provide a conservative 

basis from which to project flight planning, flight readiness 
and flight control requirements for national programs. Signi-. 
ficantly, this workload must be carried out in a secure 
environment, including compartmentation of key aspects, in order 
to protect sensitive sources, methods and capabilities. 


An analysis was made of NRP security needs for STS flight 
planning, flight readiness and flight control. While no pro- 
gram has yet gone through the complex steps involved, a descrip- 
tion of tasks outlined in the Mission Operations Plan for the 
DOD Space Transportation System Program was used by each program 
to assess security needs in each of twenty-one activities. 
Wherever these necesSary tasks are accomplished, NRP activity 
will require significant compartmentéd security. Being a 
requirements analysis, this study did not address specific 
measures to meet the compartmented or collateral security 
requirements identified. The characteristics of STS operations 
which-tend toward, if not demand, compartmented security are: 





a. When mission, payload, capability and modus 
operandi of national programs is revealed. 


b. When payload operations require extensive coordina- 
tion with STS flight control. SR Ty ae 


c. When STS on-board computers support NRP payloads 


d. When non-nominal payload conditions occur and 
Payload Specialists must interact extensively with ground 
support personnel 


; e. When basic Orbiter data is mission, capability, 
identity or modus operandi revealing 


z. When payload data is available through the Orbiter 


g. When general and special crew training procedures 
and equipment contain indicators of the mission or operations. 


In summary, this report details NRP mission and management 
control needs, projected workload and security requirements for 
the STS. Together with other DOD needs, this information forms 
the requirements base from which to analyze NRP/DOD Shuttle 
operations control options for the 1980s and beyond. 
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INTRODUCTION 


- In response to the-direction set forth in National 
Space Policy (PD/NSC-42) to review and formulate a strategy 
for the utilization of the Space Transportation System (STS) 
this document sets forth specific requirements of the National 
Reconnaissance Program to employ the STS in supporting its 
foreign intelligence collection operations. In particular, 
the requirements for mission control, workload and security are 
addressed to assure that.appropriate STS mission planning and 
operations resources will be available for National Reconnais~ 
sance Program operations from the 1980s to the mid-1990s. 
Guiding this review is the explicit recognition that a signi- 
ficant percentage of the United States’ capability to conduct 
foreign intelligence is via space systems, and that in the 
mid-1980s the STS will become the nation's sole means of gaining 
access to the space medium from which foreign intelligence activ- 


ities are conducted. 


Shuttle Employment Concepts 


There are essentially two employment concepts which charac- 
terize the range of options for using the Shuttle for NRO 
Missions: (1) use the Shuttle analogous to expendable launch 
vehicles for payload delivery only and (2) fully exploit the 
features of the Shuttle, particularly the role of_man, in the 
conduct of space operations. The "payload delivery" employment 
concept is representative of pre-1975 NRO policy whereby the 
principal concern was the transitioning of NRO payloads to the 
Shuttle. It did not reflect any attempt to exploit the Shuttle 
which at that time would have been premature considering the 
early state of Shuttle development. As the Shuttle development 
effort proceeded and a number of milestones were passed, a 
restructured NRO policy evolved from recognition that continua-~ 
tion. of a "payload delivery" employment concept was no longer 
a necessary or preferred strategy from both (a) a cost efficiency 
viewpoint if the United States is to extract maximum benefit from 
the sixteen billion dollars invested in the Shuttle program; and 
(b) an effectiveness viewpoint recognizing that the nation is — 
increasing its utilization of the space medium and therefore is 
becoming more dependent upon space systems as key instruments of 
national security. The updated NRO policy which has been in 
effect since 1978 has as a go full exninitatian af tha uttle. 
A number of new ce systems 
which are now in various stages of develop- 
ment reriect a commitment toward this goal. 
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Historically, the NRO's STS "payload delivery" employment 
concept was structured so that all interfaces between the 
spacecraft and the Shuttle be as simple as possible and that 
a dual compatible launch capability either from the Shuttle 
or an expendable launch vehicle be maintained as a hedge 
against Shuttle technological or developmental shortcomings. 
The "payload delivery" employment concept also continued the 
satellite design philosophy of the expendable launch vehicle 
era which incorporates as basic tenents extensive subsystem 
redundancy, significant simulated on-orbit ground testing 
and selection of highly reliable, long=lived components. 


The "full exploitation" employment concept recognizes 
that man can influence the overall probability of mission 
success by conducting post-launch functional checks of 
spacecraft after it experiences a launch environment (e.g., 
10 - 20% of the Space Test Program workload has experienced 
failures almost immediately after achieving orbit), by 
servicing the spacecraft or by repairing it on-orbit as 
necessary. Combined with the reusable/retrievable feature of 
the STS, which in itself is required for manned spaceflight, 
manned interaction offers an avenue for returning the space- 
craft to earth for refurbishment or extensive repair as 
warranted by the on-orbit situation. It is the ability of man 
_to interact with the payload after it experiences the launch 
environment that could result in a completely different design 
philosophy for spacecraft and potentially could yield reduc- 
tions in both the time required to develop space systems and 
the life cycle costs. For example, subsystems can be modularized 
to facilitate on-orbit servicing and repair (e.g. Multi-Mission ! 
Space : critical nrototvne subsvetems n be tested on- 
orbit thereby reducing 
the amount of ground Component testing and total system develop= 
ment time; and the Shuttle itself can be used as a mission 
vehicle substituting for the spacecraft bus itself (e.g. ZEUS, 
thereby reducing the design complexity and cost of a dedicated 
spacecraf 


























To capitalize on these features, the payload/Shuttle inter- 
_faces for this employment concept are, by necessity, much more 
complex than "payload delivery." For example, mission controllers 
and payload specialists must not only be familiar with the Orbiter 
but must also be thoroughly proficient with the payload. Missions 
will have to be planned, coordinated, rehearsed and conducted as 
an integrated operation. Traditional booster operations, and 
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other activities associated with booster operations, can no 


longer be decoupled from payload operations as the payload/ 
launch vehicle interactions become more dynamic, increase 

in number and complexity, and crew safety becomes a foremost 
consideration. . 


Concepts for Mission Control 


In spite of the recent activities to design NRO space 
systems which are more fully Shuttle optimized and to estab- 
lish a Shuttle payload specialist program for NRO applica- 
tions, the one area that has not kept pace with the progress 
made in these other areas is the requirement for mission 
control over STS flight operations in support of the "full 
exploitation" employment concept. The controlled mode con- 
cept of mission control, which evolved in 1977, had as one of 
its key assumptions the "payload delivery" employment concept 
whereby the interfaces between the Shuttle and the payload. 
were kept simple and on-orbit operations completely decoupled. 
Fundamental in the evolution of the controlled mode concept 
was the recognition that, even if the NRO/DOD were not con- 
strained by resources, there was not sufficient time nor 
facilities and expertise available within the DOD to develop a 
capability to control NRO/DOD Shuttle operations separate from 
NASA activities prior to the initial Shuttle flights upon which 
NRO/DOD cargo was manifested. Moreover, at the time, the DOD 
Mission Model (Rev 7) forecast that only two NRO missions would 
require STS launch support prior to 1985. 


However, the issue of statutory responsibilities for mission 
control remains. The controlled mode imposes some compromises 
on the time-tested procedures which have evolved for conducting 
NRO space operations. For example, care must be exercised to 
ensure that mission control capabilities and functional procedures 
are structured so that the potential for miscommunications of 
technical parameters, and the loss of training proficiency (e.g. 
generic mission simulations) created by heretofore compartmented 
functions now requiring sanitization and operations at the Secret 
level be minimized. In the past, the key to the NRO's high 
Has rate has been its ability to exercise control over all 
Sr anc the mission including planning, rehearsals, simulations 
a ese ee launch preparation, launch and recovery operations 
mi Beton ere is unity of purpose, coordinated action by all 
secusic Participants, and strict adherence to operations ; 
cae pinnae deeded che Any significant departure or erosion in 
to res ona _modus operandi could impact the ability of the NRO 
Rationst in its traditional timely and effective manner to 

a Security requirements. 
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As the NRO moves toward the goal of "full exploitation," 

mission control will exacerbate relative to the controlled 
“mode way of operating as Missions become more dynamic in 

direct relation to the degree which the Orbiter assumes a 

role as a base station (e.g. on-orbit construction), as a 
spacectaft mission platform, as a responsive vehicle for 
contingency and crisis support and a flexible means of coping 
with unscheduled or unforeseen events. Clear boundaries 
between the payload and the Orbiter diffuse as additional and 
more complex on-orbit functions enter the workload. This 
diffusion gives rise to the need to plan, simulate and conduct 
the mission as an integrated operation. It is counter- 
productive in terms of flight safety and mission success to 
‘create a situation where the Orbiter is attempting to accom- 
plish one set of functions while the payload operations are 
performing another unrelated set. Moreover, personnel assigned . 
Orbiter control functions must become more familiar with the. 
characteristics of the payload and functionally participate in 
the conduct of the mission including, in some cases where the 
Orbiter is used as a mission platform, collection of intelli- 
gence data. Control over operations security practices and 
procedures for all facets of the mission is essential to protect 
sensitive sources and methods, and will come to the forefront o 
planning and operations in the "full exploitation" mode. 


; The control infrastructure wiil aiso be impacted by the 
volume of the workload and the need to coordinate and schedule 
all NRO miSsion activities in response to national requirements. 
If the Orbiter is to be used as a mission platform to respond / 
to crisis or used for other unforeseen contingencies (e.g., a 
disabled satellite), proficiency must be maintained in all 
facets of the operation and the control infrastructure must be 
able to energize contingency packages, and ensure their orderly 
flow through a milieu of other planning, rehearsal, training 

and flight preparation activities that would be simultaneously 
On-going as part of the day-to-day operations within the Shuttle 
system. Positive control and authority to interrupt other 
activities becomes an essential element so that the Shuttle 
System can be as responsive as possible. Moreover, flight 
Planning and Shuttle exploitation activities which are asso- 
ciated with mission control functions must be coordinated among 


the various NRO programs to facilitate the development of pay- 


load-man~Orbiter performance envelopes and to identify useful 


problem-solving techniques during contingency operations (e.g. 
ing or repairing a disabled satellite). 


Servic 
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In order to achieve a more flexible operating 
posture, increase collection effectiveness, and capitalize on 
the features of the Shuttle which could potentially lead to 
reductions in the time required to develop Space systems and 
their life cycle costs, the NRO will require a control 
infrastructure different from that which already exists in the 
controlled mode concept. 


Figure 1 contrasts the degree of mission control required 
over activities. For NRP missions, the necessary control must 
encompass all facets of Shuttle flight planning and operations. 
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DEGREE OF MISSION CONTROL NEEDED TO SUPPORT: EMPLOYMENT CONCEPTS 


MISSION CONTROL ACTIVITIES 


o DYNAMIC MISSION PLANNING, DIRECTION, OPERATIONS 
ACTIVITIES 


o PAYLOAD/ORBITER IWitRFACE CONTROL 
o NUMBER OF INTERFACES 
o COMPLEXITY 


o SYSTEM RESPONSE TIME AND READINESS CONTROL | 
o CRISIS . 
o OTHER EXOGENOUS EVENTS 
O MAINTAINING TRAINING PROFICIENCY FOR CONTINGENCIES 
o OPTIMIZATION OF PAYLOAD-MAN-ORBITER PERFORMANCE 
ENVELOPES 


o COMPLEXITY OF MAINTAINING AND PROMOTING OPERATIONS 
SECURITY PRACTICES 
o TECHNOLOGY BASE 
oO ORBITAL POSTURE 


UNCLASSIFIED 
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LOW 
LOW 
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FULL 


EXPLOITATION 


HIGH 
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Prior to this review, the DOD space mission, model, including 
the latest revision (Rev 8), was the sole planning document for 
estimating DOD's flight operations requirements for the STS. 
The space mission model is a carry over from the expendable 
launch vehicle era when it was used as a planning tool for 
booster procurement and reflected only eae S 
quirements. With the single exception of (ZEUS) 
missions*, the latest space mission model for STS usage con- 
tinues to reflect only nominal payload delivery requirements 
and does not address workload requirements which more fully 
exploit the capabilities of the STS. The failure to depict 
future workloads which take advantage of the capabilities of 
the Orbiter and man in space can lead to a serious under- 
estimation of DOD needs for the STS and associated flight 
planning, readiness and control functions. 





A dichotomy with respect to STS mission planning was painted in 
the management section above. In most prior planning, the STS 
was viewed only as a booster and the payloads would be designed 
to minimize interfaces with the shuttle.- As the pace of 
activities to transition NRP and DOD payloads to the shuttle 
has accelerated, recognition of the shuttle's potential as a 
mission platform has grown. Studies were made of how to ex- 
ploit the presence of man in space, how to exploit and enhance 
the STS itself, and to determine requirements for military pay- 
load specialists. If these programs are followed even in part, 
a new expanded definition of STS workload in flight operations 
planning, readiness and control needs to be developed. The 
workload presented below assumes exploitatian of the STS be- 











yond delivery of free flying paylo Further, it reflects 
on to employ the STS in th 
program. ‘* ‘ 


TYPES OF WORKLOADS. The STS can be exploited beyond its capa- 

itity for taking payloads into space. The full range of 
potential applications or workload categories for the use of 
the STS are defined below. ** 


penne we 
* 


Denoted as Support Mission V and included in the DOD 
Space mission model (Rev 8). 


ak 


eiaae task team on "Future Space Transportation Needs" in 
FY1980 ‘ ee the Presidentially-directed crosscut review of the 
cre Ais get has focused on future enhancement options for the 
heroin Capabilities will permit more efficient _ 

to cana ment of currently planned missions or the capability 
uct others. However, any new tasks or missions can be 


cast i : ‘ : . . 
eee the basic workload categories established in this 
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Payload delivery is the delivery and injection of payloads: 
into orbit. This function includes on-orbit checkout of pay- 
loads and return of those not able to be repaired by the crew. 


Retrieval is the capture of orbiting payloads or objects 
from orbit using the STS in order to perform a specific 
activity. , 
























Repair/service are two similar activities associated with 
retrieval. Repair is the,activity which involves repairing or 
replacing spacecraft components rendering them operable again 
so that the spacecraft may function as designed. Service is 
the activity of replenishing by refueling, recharging or 
changeout of marginal modules. 


Construction is the building or erection of a variety of 
large space structures using the STS as the base station for 
assembly and construction activity. 








Orbiter use the Orbiter as the platform 
for military, intelligence and R&D tasks. This includes pay- 
loads affixed to the Orbiter with or without using the Orbiter 
crew or on-board payload technicians. ; 





UTILITY OF THE WORKLOAD. Some lessons learned regarding space 
system reliability during the last two decades differ from 
theoretical expectations devised at the beginning of the space 
age. The majority of system failures are booster failures* or 
“infant failures" because they occur at initial turn-on or 

‘@arly in a system's operations. Subsequént launches and 

System reliability statistics generally reflect lessons learned 

early program failure. The failure rate of parts during 

@rbital life once they have survived “infant mortality" has _ 

far lower than original expectations. As a consequence, 

© S@tellites which survived boost and “infant mortality" phases 

| @%@ much longer-lived than Mean Mission Durations (MMD's)’ 
*stinates. The hackinda af NED and trancit enar craft and the 

s@ag~lived Teese one 

eas nN point. With the advent of a reliable Orbiter 

ee vie ooster and payload specialists for on-orbit checkout 

. se the major sources of overall mission failure should 
Hart iaiipe Perches Lack of critical satellite coverage, 
i a ser i i ha 

Shriated, irly recent DSCS II launch failure, walt NCA) 

(b)(3) 

10 USC + 424 


hd t eote of 92 high altitude satellite launches, 20 

filed. Of the subsequent 20 satellite failures during 

; ene pre lifetime, eight were TWT's and five electrical 

SHR Seug Program. Rand WN-9551-PR, Rand Spacecraft Acquisi- 
Ye August 1976. ; 








42a 
Based 
on Rand and TRW reports and briefings 
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In addition, spacecraft sensors or systems may use more 


“capable but higher risk technologies in the STS era knowing 


that on-orbit access for repair can be designed into a space- 
craft. Some present spacecraft are destroyed by deboosting 
when their film is expended or other expendables are depleted. 
New generations of spacecraft could be serviced with film, 
fuel, batteries, etc., from the Orbiter. An electronic 

"block change," such as changing SIGINT frequency coverage 
could also be accomplYished. 














Periodic 











refurbishment of such systems would be possible from the STS. 


The construction of large antenna structures in space or 
assembly of propulsive systems for orbit maneuver or for 
taking payloads beyond geosynchronous altitudes enhances US 
capability and flexibility to perform many DOD/NRO missions in 
space. 

















EXPANDED WORKLOAD IMPLICATIONS. From a workload standpoint 
Payload Delivery of free flyers represents nearly all of the 
activity incorporated in the present mission model. Repair 
and Service and Retrieval represents additional workload since 
beara time and extensive planning, preparation and training 
oe te necessary. An important caveat is that satellites 
ana Aiea designed for repair and service consistant with safety 
poi factors in the space environment. Likewise much 
deveis = be done to design satellites for retrieval and to 
pene née necessary techniques, procedures and equipment. 
But we Sid ae of these operations have yet to be fully assessed. 
Baneuverin assume that if improved and larger duration 

on fe are procured man's EVA capabilities and 

Orbit will be extended. Training, planning and con- 


trol Wee ty : : 

worklosd nose , activities will have to be factored into overall 
considerations. In about a decade, experience may 

eee 


2 
| Rand WN-9 351-PR OPCIT. 
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permit construction and assembly of large structures in space, 
a workload involving several Shuttle loads of cargo and 
several days in orbit for assembly. 


However, the most significant near-term additive workload con- 
sideration is the Orbit Platform activity. The duration of 
these missions (whose payloads are returned with the Orbiter) 
range anywhere from one day to perhaps three weeks. This 
category includes both operational and R&D payloads. The 

ZEUS, and R&D programs are examples which exploit 
this concept. This type of activity allows for payload optimi- 
zation by designing for manned interface to provide optimal or 
flexible system collection, and system repair or servicing. A 
payload could be built to use STS self-contained expendables or 
equipment thereby reducing costs and/or payload complexity. 














FORECASTING OF WORKLOAD 


Considerable uncertainty accompanies any STS workload pro- 
jection. The principal problem is that plans must attempt to 
convey STS usage in a 1980's environment based on a 1970's 
perspective and without benefit of any operational experience 


with the STS. We consider both scheduled and contingency work- 
load. 7 : 


Scheduled workload includes planned launch and deployment 
of payloads n rievals,, planned repair and service and 
planned Construction missions are always in 
the planned category. Flight planning, readiness and control 


are accomplished on a routine, preplanned, non-crisis basis 
insofar as possible. 








Contingency mission workload includes launch on demand which 
can have significant schedule impact when it occurs. The 
Priority for national programs stated in National Space Policy 
(PD/NSC-37) may dictate that cargo be launched on the next 
available Orbiter. Contingency workloads are difficult to 
define for several reasons. The first is the magnitude and 
number of contingency events, such as international crises, 
Which cannot be forecast with certainty.* For estimation pur- 
poses, this problem may be handled statistically; i.e., based 
ri historical trends, one might expect from three to six 

ernational crises per year involving the political use of 
eaesenn. forces short of ground conflict which could require 
nd launches. Secondly, and probably more importantly, 

See space Systems with significant utility for crisis support 


a 
Gener ce Without War," Brookings Institute, 1978; and "A 
Wreta won Of Crises: 22 Sketches of U.S. Interventions Since 





i Rand Corp. 1972 
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such as ZEUS and systems 
are still in the definition phase... As development proceeds, 
planning for their availability and uSe in times of crisis 
will become better defined. Further, space may become the 
arena for early hostilities. | | 
| [and emergency replacement 


could be significant. The contingency workload is very likely 
understated. 




















The priority. and nature of the contingency workload will 
require that planning, training/rehearsals, and control per- 
sonnel and systems be current and exercised regularly. 


While the ingency workload is expected to fall most 
heavily in the workload category, contingency workload 
can be anticipated in the payload delivery (replace upon 
failure), retrieval, and repair/service categories as well. 


STS WORKLOAD ESTIMATES 


/ 


The System Program Offices in Programs A, B, and C 
estimated their STS-related workload requirements based up- 
on the following assumptions: full exploitation of the STS 
will proceed; payloads will experience evolutionary changes 
to optimize payload/payload specialist/STS interactions; and 
STS flights will be conducted on a routine basis. The 
summarization of these estimates is shown in Tables 1 through 
4. These inputs include "approved" programs which appear in 
the DOD Space Mission Model (Rev 8) and programs which have 
not been formally approved such as R&D demonstrations or 
advanced versions of present systems. 


_ Table 1 displays STS workload for the Eastern Launch 
Site (ELS) at Kennedy Space Center and the Western Launch 
Site (WLS) at Vandenberg AFB. The appropriate support mission 
(SM I through SM V) is used to permit ready comparison with 
the launch-oriented STS portion of the DOD Space Mission 
Model, Revision 8. In this breakout, missions requiring a 
dedicated Shuttle launch indicate NO in the Ride Share column. 
Payloads to be launched which are potential ride share candi- 
dates have a YES in the Ride Share column. To be consistent 


lobe the mission model counting procedure, each is counted 


The missions presented in Table 1 are consistent with the 
President 


lie ae FY-80 approved program through FY-1985, the outyear 
FY-1999 ions of that program through 1991. The forecast from 
lishea through FY-1995 generally continues patterns estab- 
+n earlier years. Table 1 shows a break at FY-1991 in 


18 

















Approved for Release: 2017/02/27 C05094780 


Approved for Release: 2017/02/27 C05094780 


BYE~-112763-79 


order to facilitate comparison with the NRP inputs, dated 

13 Feb 79, to Revision 8 of the DOD Space Mission Model 

(see Table 5). Table 1 may be directly compared with = 
Table 5, the NRO STS Mission Model (Rev 8). The specific STS 
Rev 8 differences between Table 1 and Table 5 are as follows: 


4 compen nee SNL FUER 








| : PROGRAM TABLE 1 FY 


SOME CRETE Tae I oe 








r ZEUS" 84 | 
b)(1) 
b) 


3) 
0 USC + 424 











Net Difference (Table 5 - Table 1) 


Total Table 1 (Delivery 


Total Table 5 (Rev 8) 


( 
( 
1 











“NOTE: TABLE 1 shows ZEUS as a pallet program with two 
missions from ELS and 1 mission from WSL each year. 
This is consistent with current program planning. 
TABLE 5 shows ZEUS with 3 missions 




















each year from WLS. 





Note the NRO STS Mission Model (Rev 8) numbers have 
been corrected from those reflected in Table 1 of the SAFSP 


Shuttle Requirements Report (Preliminary) 10 May 1979. The 
number of payloads in 1986, 1987 and 1989 chanae from 














These changes reflect 
program. 





=sajyusStmMents to be made in the - 








rams 
scheduled in the FY-1987 
time frame and beyond show retrieval activity projected to 
be accomplished on the same STS mission which deploys a like 
Spacecraft. While the scheduled number of STS flights is 
not increased thereby, this does represent an increased STS 


Planning, training and readiness, and operational control 
Workload. 








Note further that three iii 
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As it is necessary to display STS workload requirements 
for NRP missions at the DOD SECRET level for integration 
with other DOD workload, Support Mission designations are 
used to identify requirements without referemce to NRP pro- 
grams. Table 5 breaks out NRP programs by support mission 
and indicates the first Shuttle launch for each program at 
KSC or VAFB as appropriate. All subsequent Launches are on 
the Shuttle. Table 6 presents the sanitized launch model 
corresponding to Table 5. This’input is combined with in- 
puts from other DOD programs to construct the DOD Space 
Mission Model which is provided for reference as Table 7. 


A word of caution in interpretation of STS launch require- 
ments is in order. In all tables displaying launch-oriented 
workload, some potential for ride sharing is suggested. For 
example, see the "total Shuttle flights" line for ESL and 
WLS in Table 7. Since detailed compatibility of payloads 
can only be determined on a case-by-case basis and cannot be 
assessed at this time, any total Shuttle laumch flight 
numbers should be viewed with caution. The totals by fiscal 
year in Tables 1 and 5 must be understood as payloads for 
¢elivery into orbit plus This number is 
clearly an upper bound on scheduled Shuttle Launches. Because 
of ride Sharing, the real number of Shuttle Launches to meet 
scheduled requirements will likely be less. The policy for 
RP payload ride sharing is that NRP programs will consider 
tide sharing with other NRP programs and with DOD programs 


Consistent with technical compatibility and maintenance of 
Program security. 














(b)(1) 
(b)(3) 10 USC + 424 
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As it is necessary to display STS workload requirements 
for NRP missions at the DOD SECRET level for integration 
with other DOD workload, Support Mission designations are 
used to identify requirements without reference to NRP pro- 
grams. Table 5 breaks out NRP programs by stspport mission 
and indicates the first Shuttle launch for each program at 
KSC or VAFB as appropriate. All subsequent Launches are on 
the Shuttle. Table 6 presents the sanitized launch model 
corresponding to Table 5. This’input is combined with in-. 
puts from other DOD programs to construct the DOD Space 
Mission Model which is provided for reference as Table 7. 


A word of caution in interpretation of SFS launch require- 
ments is in order. In all tables displaying Launch-oriented 
workload, some potential for ride sharing is suggested. For 
example, see the "total Shuttle flights" line for ESL and 
WLS in Table 7. Since detailed compatibility of payloads 
can only be determined on a case-by-case basis and cannot be 
assessed at this time, any total Shuttle laumch flight 
numbers should be viewed with caution. The totals by fiscal 
year in Tables 1 and 5 must be understood as payloads for 
delivery into orbit plus | This number is 
Clearly an upper bound on scheduled Shuttle Launches. Because 
of ride Sharing, the real number of Shuttle Launches to meet 
Scheduled requirements will likely be less. The policy for 
WRP payload ride sharing is that NRP programs will consider 
ride sharing with other NRP programs and with DOD programs 
consistent with technical compatibility and maintenance of 
program security. 
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(b)(3) 10 USC + 424 


20. 


- SY tM wy, ; 
a ale bh =e 
= ETNiTS aie 





Oe pe ae 





Approved for Release: 2017/02/27 C05094780 


RECT a EE SIE Ty eo me rarpereN ra tome Mepe ergey yore 











Approved for Release: 2017/02/27 C05094780 


BYE-112763~-79 


As it is necessary to display STS workload requirements 
for NRP missions at the DOD SECRET level for integration 
with other DOD workload, Support Mission designations are 
used to identify requirements without referemce to NRP pro- 
grams. Table 5 breaks out NRP programs by support mission 
and indicates the first Shuttle launch for each program at 
KSC or VAFB aS appropriate. All subsequent Launches are on 
the Shuttle. Table 6 presents the sanitized launch model 
corresponding to Table 5. This-input is combined with in- 
puts from other DOD programs to construct the DOD Space 
Mission Model which is provided for reference as Table 7. 


A word of caution in interpretation of SFS launch require- 
ments is in order. In all tables displaying launch-oriented 
workload, some potential for ride sharing is suggested. For 
example, see the "total Shuttle flights” line for ESL and 
WLS in Table 7. Since detailed compatibility of payloads 
can only be determined on a case~by-case basis and cannot be 
assessed at this time, any total Shuttle laumch flight 
numbers should be viewed with caution. The totals by fiscal 
year in Tables 1 and 5 must be understood as payloads for 
delivery into orbit plus This number is.-. 
clearly an upper bound on scheduled Shuttle Launches. Because 
of ride sharing, the real number of Shuttle Launches to meet 
scheduled requirements will likely be less. The policy for 
RP payload ride sharing is that NRP programs will consider 
tide sharing with other NRP programs and with DOD programs 
consistent with technical compatibility and maintenance of 
Program security. 
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A similar caveat applies to mission sharing , i.e., the 
compatibility of accomplishing more than one type of workload 
on a single STS flight. The retrieval of a payload following 
delivery of a similar payload is an example for which mission 
compatibility was assumed in Table 1. Retrieval, repair and 
service operations in conjunction with a payload delivery 
or | could, become very complicated because of 
specialized equipment for these tasks which would need to be 
carried by the Shuttle. Hence, mission compatibility can 
only be assessed on a case-by-case basis, cannot be determined 
at this time, and will only be possible when essential program 
security can be maintained throughout the mission. 








In support of the OMB-directed study of Space Transportat- 
ion System Flight Control Requirements, NRP STS workload in 
sanitized form was transmitted to SAMSO for inelusion in the 
consolidated STS workload forecast and security baseline. 

That submittal is inclosed as Attachment 2. Table 1 of 

Attachment 2 can be directly compared with Table 1 in the main 

body of this report. = 3 (b)(1) 
eo (b)(3) 

Table 2 displays NRP potential contingency STS workloe10 USC | 424 
It includes applicable programs currently shown in the DOD 
Space Mission Model. Additionally, an | 
| ZEUS contingency missions from either 
ELS or Vandenberg. The| [programs both are 
protecting for one contingency delivery/retrieval mission or 
one repair/service mission each year. For planning purposes, 
these are shown in alternate years commencing in FY 85. Since 
contingency workload on each of the programs shown may or may 
not occur in any given year, an estimated range of one to 
three contingency support missions is shown for each year. 
Similarly, the number of contingency operations which might 
occur through 1991 is conservatively estimated as 3 to 10. 























Contingency workload is not presently incorporated in the 
DOD Space Mission Model. Table 2 of Atch 2 directly cor- 
responds to Table 2 of the main body of this report and trans- 
mitted contingency requirements for use in the OMB study. 


Table 3 presents NRP potential R&D workload for the STS. 
No NRP R&D workload is presently incorporated in the DOD Space 
Mission Model. The R&D workload encompasses both program/ 
eee Oriented R&D and a sustaining program of brassboard, 

beat and component testing. While not all items on 
erivis e of R&D activities will come to pass, a non- 
eouta fraction will be carried out. If successful, they 
Tesult in new capabilities and be reflected in scheduled 


2.1 
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or contingency workload in the outyears. Some new systems 
may replace or lessen the need for present systems. Such 
possibilities are not reflected in Tables 1 or 2 above since 
to do so would be unduely speculative and perhaps imply 
analyses which have not been done, for example preferred 
mixes of imagery, SIGINT, or crisis support assets. Each R&D 
project is briefly described in accompanying footnotes. 


Some potential R&D projects could involve on-orbit con- 
struction beginning in the 1990 time frame. We envision 
dedicated shuttle flights, extensive RMS and EVA activity, 
and usually multiple launches to support construction of a 
single system. Mission duration is difficult to predict at 
this time because of uncertainties in payload size and weight, 
orbiter support services and kits, and orbiter station keep- 
ing needs. For purposes of this report, a typical construc- 
tion mission is assumed to use one flight for station keeping 
with a MOL-type life support system in the cargo bay to 
support the construction crew for several days to a few weeks. 


One or two other dedicated flights would deliver hardware to 
orbit. 


4 


The: shuttle cargo bay characterization experiments to ; 
potentially start in FY-81 and the integration system experi- 
Ments in the FY-83, 84 and 85 period derive from studies, 
conceptual designs and limited hardware tests conducted or 
now underway. For example, BYEMAN| is defining 
instrumentation and experiments to characterize the cargo bay 
environment so as to provide more comprehensive design 
criteria for other NRP payloads transitioning to the shuttle. 
The integrated system experiments can be developed to meet the 
Schedule depicted in Table 3 if a commitment to the particular 
experiment is made in FY-80 with appropriate funding in sub- 
sequent years. Therefore, schedules shown are possible and 
tealistic given program go-aheads but must be understood as 
potential workload not approved at this time. 











On average, 3-4 subsystem experiments per year are ex- 
pected commencing in FY-86. ‘These experiments will capitalize 
@a man in space as an experimenter to demonstrate technology 
@ad to test, checkout, and space test subsystem hardware. 
Thean?* Of 3-9 component tests per year are anticipated. 
pounds moment tests are typically lightweight (up to 250 
Bach 3. Sealed cannisters of about five cubic feet volume. 
Specialj eo sssble by four commands from the payload 

1St. Component tests are compatible with NASA's 


(6)(1) 
(b)(3) 10 USC + 424 
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"getaway special" space tests for experimenters advertised 
for $10,000. While subsystem and component tests will be 
ride-share, space available shuttle cargo, they nonetheless 
represent important workload in integration, crew activity 
planning and training, and operational support. Table 3 in 
Atch 2 summarizes potential R&D workload devoid of program 
specific detail so it can be used for workload planning by 
the SAMSO and NASA. 




























Table 4 summarizes all potential STS workload in 
scheduled, contingency, and R&D (dedicated, ride-share, and 
small package ride-share). The potential range of NRP 
activity is shown for each fiscal year. The small package 
(space available, ride-share) and subsystem R&D is displayed 
separately at the bottom. With the exception of scheduled 
workload, a range of activity through FY-91 is shown. The 
scheduled workload is eSsentially captured in the present DOD 
Space Mission Model but all other contingency and R&D work- 
load is not. Because of uncertainties in demand for con- 
tingency support, the cumulative total through FY-91 is not 
additive across columns but rather is our estimate of the 
range of contingency support over the seven year period. 
Similarly, the range of all scheduled, contingency and R&D 
workload is not always directly additive in each fiscal year 
column. Instead, a deflated range of activity is displayed 
which in our judgement accounts for uncertainties in con- 
tingency demand and R&D program starts. 


The STS workload presented herein can provide a basis to 
forecast demand for flight planning, flight readiness, and 
flight control activities, personnel and facilities. This 
Ssput when combined with other DOD Space program workload is 
the forcing function to drive support requirements. In this 
nt, no attempt has been made to analyze or derive 
tansformation functions which relate the forcing function to 
Specific task loadings on facilities, training devices, 

Beer ralaee control rooms, orbiters, ADP equipment, time on 
Sst, etal. That essential task is the next step. 


OE ita of mission sharing and ride-sharing, projections of 
Shuttle days on orbit are frought with considerable un- 
Sead d ty. JA two day duratian might typify free-flyer pay- 

| rahe with an additional day if a retrieval of a like 
© derrcing: accomplished on the same mission. Repair, : 

§ Or retrieval missions would likely require about 
an oe days per satellite contacted. On orbit duration 
RS Cal ZEUS mission is 21 days. At three scheduled 

“ ons per year and potential contingency missions 
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whose duration could approach 21 days, the use of the STS in 
a represents a significant portion of DOD's on- 














In the late 1980s, follow-on operational versions of 
several R&D systems designed for contingency support will 
operate in the and potentially increase Shuttle 
on-orbit time. As noted earlier, contingency workload could. 
be understated because the full potential for the STS as a 
mission platform to support crisis and wartime needs is not 
Clear at present. (b)(1) a 
(b)(3) 10 USC + 424 «45 














CONCLUSIONS 


The NRO workload is not properly estimated in the current 
mission model, which is essentially payload-delivery oriented. 


Contingency workload in support of crisis operations is 
significant and probably understated because the full potential 
exploitation of the STS is not yet understood and readiness of i 
crews for these missions must be maintained. a 


Projected NRP R&D workload includes a few dedicated flights 
but most are ride-share candidates. R&D workload will be 
superimposed upon the scheduled NRP and DOD workload. 
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Three NRP payload delivery and kare 
scheduled prior to FY-85: in Fy-82, 
another in FY=83, and an in FY-83. 














Because of lack of experience; requirements for repair/ a 
servicing and retrieval are probably understated by the pro- > 


On-orbit construction when it occurs significantly impacts ‘| 
On-orbit time requirements. 





Workload estimates in this review provide a conservative 
basis from which to project flight planning, flight readiness 
‘and flight control requirements for national programs. 
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SECURITY 


INTRODUCTION 


Space systems are now being described at the highest 
national level as the most valuable and dependable source 
of foreign intelligence for the United States. In addition, 
adaptations and modifications are underway to provide real- 
time intelligence from space systems to military commands 
and the battlefield environment. The continued availability 
of satellites for accurate and timely intelligence has be- 
come crucial for critical diplomatic and defense decisions. 


A vast amount of evidence has been compiled on the Soviet 
efforts to defeat the effectiveness of the United States' 
space-based intelligence collection efforts. The focus of 
this program is to employ deception and to camouflage, cover 
up and conduct activities out of range, sequence or scope of 
the U.S. space/intelligence systems. In support of these 
operations a well-developed satellite alert system is in 
effect. Generally, the total program is referred to by the 
U.S. Intelligence Community as the Cover, Camouflage and 
Deception Program (CC&D). By understanding system missions' 
operational capability and deployment strategy, scenes can be 
contrived, decoys employed, spurious electronic signals issued 
and disinformation fed through collected communication channels 
to mislead national planners and military commanders to wrong 
decisions. In recognition of the critical relationship be- 
tween success in keeping the intelligence methods and sources 
from the target state and the continued success of the col- 
lection mission, the principal objective of NRO security is 
to reduce the effectiveness of Soviet CC&D against the NRP 
collection program. 


The employment of the Space Transportation System. 
(Shuttle) and supporting systems, if properly approached and 
secured, offers the opportunity to counter the effects of 
Soviet CC&D through more imaginative space operations and 
better security than now exists. The Shuttle itself will 
provide a standard launch cocoon enabling the obscuration of 
all payloads. To capitalize on these opportunities, BYEMAN 
compartmentation and the day-to-day intelligence standards of 
security must be incorporatéd as an integral part of the 
Shuttle/NRP mission operations, flight planning and prepara- 
tions activity. Inherent in these procedures are strict 
access and observation control of all mission-revealing in- 
formation and activity. Considéring the long-term investment 
in each space intelligence collection system, a short fall in 
Security would not be prudent. 
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Protecting system capabilities involves safeguarding *S 
information which reveals: 


Missions and Mission Elements 
Design Capabilities and Limitations 
Actual/Demonstrated Capabilities and Limitations 


System Vulnerabilities and Measures Taken to Enhance 
Survivability 


Products, i.e., Raw Processed Data and Analyses 


Further, protecting system capabilities involve denying, 
delaying and misdirecting enemy countermeasures. 


Protecting system modus operandi involves safeguarding 
information which reveals: 


Tasks, Tasking Priorities, Tasking Response 

Synergisms Between Systems, System Dependencies 

Operations Concept as Designed and as Implemented 

Deployment Strategy, Schedule, Pipeline Response 

System Status 

Ground Station Missions and Capabilitiés 

Support Systems 

Security is used to create and enhance a protected en- 

vironment for the conduct of NRP space operations. This 


includes: 


Support Favorable International Relations 





(b)(1) 
(b)(3) 10 USC 4 424 











Legitimacy of Space Systems 


Physical Electromagnetic, Communications, Operations 
and Personnel Security 


Public Information 
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Protection of Relationships/Associations: between U.S. 
government organizations, and between government 
‘organizations, contractors and individuals 


NRP security is developed and carried out within the 
above framework. In this study, NRP security needs were 
analyzed in the framework of STS operations as described 
next. 


METHODOLOGY 


Each NRP program develops appropriate security classifi- 
cation guidance covering all aspects of its development and 
operation including both sensitive compartmented activities 
and less sensitive non~compartmented activities such as 
some launch base and range support for which DOD collateral 
security provides adequate protection. In this review, the 
.study team and the program offices identified information, 
operations and procedures involved in: shuttle flight plan- 
ning, flight readiness and flight control which require 
security protection. Basic criteria for determining the 
classification of any item of information derive from the 
need to protect sensitive sources and methods and thereby 
enhance the effectiveness of NRP space systems as discussed 
above. 

STS flight operations wherever conducted will involve 
Flight Planning, Flight Readiness and Flight Control activi- 
ties. These activities aré based on the successful pattern 
followed by NASA on the APOLLO and SKYLAB misSions. While 
no program has fully gone through the steps leading to a 
STS launch, a comprehensive description of the tasks ex- 
pected in each activity has recently been published as the 
Mission Operations Plan for the DOD Space Transportation 
System Program, SAMSO-LV-0020, Jan 1979. The detailed 
descriptions in this document were not available to all 
system program offices at the time of this survey, but very 
brief, generalized descriptions of the twenty-one functions 
included in-flight planning, readiness and control were pro- 
vided. “Each program was asked to assess the highest 
security level required to conduct program specific tasks 
in each of the twenty-one functions. Each was asked to 
indicate why this security level was necessary. This data 
enables estimation of the sécurity envelope needed by each 
program and by the NRP as a whole for these activities. 





The initial inputs received from the program offices 
surveyed reflected not only the different needs of the 


. 
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individual programs but also suggested that the program 
offices had different interpretations. of the tasks and in- 
_formation needs of each of the 21 functions. That depth 

of insight can only be gleaned from study of the compre- 
hensive LV-0020 document or extensive personal experience 
with manned spaceflight operations planning. In the opinion 
of the NRP STS requirements study team, the programs have 
probably tended to underestimate security needs because they 
lacked full appreciation of the extent to which sensitive 
program data permeates the flight operations planning, readi-~ 
ness and control process. As a result, the study team 
developed more detailed descriptions of each of the 21 func- 
tions for review by the program offices. The results of the 
second security assessment are shown in Table 8. The de- 


tailed descriptions, Attachment 1 to this Annex, are provided 
for reference. 


SECURITY REQUIREMENTS ASSESSMENT 


Table 8 summarizes the highest security level assessed 
by each program as necessary to accomplish each of the 
tyenty-one functions. A requirement for sensitive compart— 
mented information means that TOP SECRET or SECRET BYEMAN 
information is involved in that activity. In rare instances, 
SI/TK information may be involved. 


. The security requirements shown are independent of where 
the activity is to take place, i.e., in a DOD Shuttle Opera- 
tions Center, at Johnson Space Center, at a contractor's 
facility or at any other government facility. Further, no 
effort has been made to assess how the requirement might be 
Met at any given facility. Alternatives to satisfy these 
requirements at various locations are to be addressed in the 
OMB-directed study of alternative shuttle control options. 


Table 9 summarizes NRP STS security requirements by 
workload class for each of the 21 functions comprising the 
flight planning, readiness and control elements. In some 
instances a range of security requirements 15 shown to re- 


flect differences in program needs or that one or more levels 


are believed necessary. The overall NRP requirement is 
stated in the last column. ‘he abbreviation TSC standing 
for TOP SECRET Compartmented means a TOP SECRET BYEMAN, 
SECRET BYEMAN or rarely, SI/TK information is required for 
this meaning 
to the non-BYEMAN, non-compartmented world. Table 5 in 
Attachment 2 corresponding directly to Table 9 here was 


used to transmit the overall highest security requirements 


from SAFSP to SAMSO/LV for use in analyzing shuttle opera- 
tion control needs. 


. 
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STS SECURITY REQUIREMENTS BASELINE - SUMMARY 


STS MISSION OPERATIONS ELEMENT 


“PLIGHT PLANNING 


1. 
2. 


3. 
4. 


5. 
6. 


Flight Feasibility Analysis 
Payload Flight Support 
Requirements Development 

STS Utilization Planning (Payload 
Mix, Flight Assignment) 

STS Flight Design 

Upper Stage Flight Design 

Flight Crew Activities Planning 


*PLIGHT READINESS 


i. 
2. 


3. 


4. 
5. 


6. 


7. 


Flight Data Pile Preparation 
SSV On~Board Digital Bata 
Load Preparation 

Upper Stage On-Board Digital 
Data Load Preparation 

Flight Crew Training 

SSV Flight Operations Support 
Personnel Training 

Payload Flight Operations 
Support Personnel Training 
Integrated Rehearsals and 
Simulations 


*FLIGHT CONTROL 


6. 
7. 


. & 


SSV Flight Operations Planning 
Payload Flight Operations 
Planning : 

SSV Prelaunch Operations 
Payload Prelaunch Operations 


}. SSV Flight Operations Support 


(launch, on-orbit, recovery) 
Payload Flight Operations 
Support 

SSV Operations Post-Flight 
Analysis 

Payload Operations Post-Flight 
Analysis 


eee 


= 


REPAIR 
& 
DEPLOY SERVICE 


TSC TSC 
S->TSC S->TSC 


S->TSC S->TSC 
S->TSC S->TSCc 


N/A=>TSC N/A 
S-9TSC S—)>TSC 


S—>TSC 
S-)TSC 


N/A=>TSC 


$ & TSC 
s 


tTsc 


S->TSC 


Ref: DOD STS Mission Operation Plan (SAMSO/LV-0020, Jan 79)_ 


KEY: S = DOD SECRET 


penne 


TSC = TOP SECRET Compartmented 
N/A = Not Applicable 


—> Indicates Range of Requirement 


780 


TABLE 9 


CONSTRUC~ 
TION 


TSC 
Ts¢ 


N/A->TSC 


§ & TSC 
Ts¢ 


N/A->TSC 


TtTsc 





& Indicates both security levels are required 
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DISCUSSION 


In this section we draw some general observations re-~ 
garding security needs specified by NRP programs and pro- 
jects. We shall also present a few detailed examples to 
illustrate why compartmented security is required. Lastly, 
having surveyed the NRP projects and’ summarized their 
security needs with respect to space shuttle planning and 
operations, we draw out some characteristics of operations i 
on the shuttle which tend toward, if not demand, compart- : 
mentation. 

































Consider Tables 8 and 9. In general, NRP programs require 
compartmented security to conduct Flight Planning because a great 
deal of program information which reveals mission, operations, 
identity or capability of the spacecraft is exposed up to four 
years prior to launch. NRP programs will need compartmented 
facilities including appropriate computers, analysis and engineer- 
ing aids, simulators and crew activity planning capabilities. 
While some aspects of STS flight design may be done at the DOD 
Secret level, most require compartmented security protection : 
because of sensitive program-specific information. There is i 
essentially no difference in security requirements for the e 
flight planning functions across the five categories of NRP : 
workload. Differences between the overall NRP security require~ 
ment and the security needs of specific programs are usually 


caused by program-specific items such as upper stages or the 
amount of crew interaction. 


Overall, NRP programs require compartmented security to 
adequately conduct Flight Readiness functions. We found essen- 
tially no differences in security requirements across the 
workload categories from payload delivery to construction. é 
Flight data files used by the crew will necessarily contain 
compartmented data; hence, areas in which they are prepared must { 
be compartmented. The digital data loads for the SSV and any ; 


upper stage may contain compartmented information if the computers 
on the SSV or upper stage support checkout or operations of NRP 
payloads. Mission specific software and data loads for these 
computers must be developed in compartmented areas. While much 
flight crew training can be generic, a great deal of payload 
Specialist training will necessarily be program specific, hands- 
On work with the real hardware or computer-aided simulations 


using the real parameters. The missions are too important to do oat 
Otherwise. 
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Flight Readiness element requires the most intensive 
security environment, especially with regard to providing 
realistic training for flight crew proficiency and man/machine 
compatibility. This is the arena where engineering concepts, 
procedural approaches, techniques and individual flight crew 
member abilities are tested and evaluated. Actual payload 
hardware/procedures must be tested to measure capabilities, 
establish timelines, and explore contingency situations. Work- 
around methods to satisfy security requirements could jeopardize 
mission success if proper familiarity is not achieved during 
flight simulations/rehearsals. Fully compartmented simulation/ 
rehearsal techniques are mandatory for the portions of the 
flight directly related to or interactive with the payload. 
Flight operations support personnel in many cases must receive 
very specific program training to adequately understand and 
properly support NRP operations. Payload support operations 
personnel at the STC and coordination personnel at the SSV 
flight control center require compartmented training. 


Compartmented ‘security is required to adequately conduct 
Flight Control functions for NRP programs. Flight Control func- 
tions are easiest for deployable free-flyers. If events always 
proceeded nominally, then DOD Secret could suffice for this type 
of workload. However, the use of the Payload Specialist and the 
Orbiter avionics and computer for troubleshooting or operations 
drives toward compartmentation because of the presence of program 
specific information. 


Turning finally to the flight control elements, SSV pre- 
launch activities are often adequately protected at,the DOD Secret 
level since payloads are essentially inert at this time and most 
activities are of a readiness nature. The security level required 
for SSV flight opérations support of NRP programs varies depending 
‘on the particular program. In general, the greater the crew 
interaction with the payload and the more frequently the Orbiter ~ 
itself must support the payload operation through maneuvers of all 
kinds, the greater is the need for compartmented security. In 
particular, reaction to and resolution of an Orbiter or a payload 
system anomaly will require close coordination between Flight 
Control and Payload Operations personnel. An Orbiter problem 
can affect payload tasking, delay payload deployment or threaten 
payload health, while a payload problem could require changes to 
Orbiter flight schedule, attitude, power system or even threaten 
Orbiter health. A coordination process which requires security 
workarounds becomes unacceptable when Orbiter/crew/payload inter- 
action is great. In all cases, compartmented areas are needed 
for on-orbit payload support operations. Most post-flight 
assessments of STS performance can be conducted at the DOD Secret 
level, but some may require compartmented protection. 
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Some generalized security requiréments emerged. 


























A second common area is data displays. 
Many payload related displays will be:strictly compartmented. 
Common Orbiter displays available in flight control rooms and 
multi-purpose support rooms will have to be reviewed that 
mission-revealing information is properly protected. 





The software build and verification process is not well 
understood by DOD and few programs have made any plans to 
exploit the Orbiter's computers. The feasibility of isolating 
one of the Orbiter's general purpose computers has been analyzed 
by IBM. They determined that currently-available measures in 
the Orbiter's data processing system would provide at least 
three levels of depth in system-to-system isolation for security. 
The software build and verification of such capabilities would 
likely be compartmented. , (b)(1) 


(b)(3) 10 USC + 424 


CHARACTERISTICS WHICH TEND TOWARD COMPARTMENTATION IN_ STs OPERATIONS 


Several factors to the extent each is present in Flight 
Planning, Flight Readiness and Flight Control activities demand 
or push toward specially compartmented security for that activity. 
Table 10 lists these factors. The first factor, discussed in the 
Introduction to the Security Section of this report, provides the 
fundamental basis for classification. The remaining factors were 
not themselves used as criteria to judge whether or not compart- 
mented security is needed. Rather, these factors emerge as 
independent explanations and descriptions of those situations 
wherein compartmented STS flight operations have been found to 
be necessary employing fundamental criteria for classification of 
program information. 


The mere presence of one or more of these explanatory factors 
does not of itself always guarantee that compartmented security 
must be implemented. In some instances lower levels of classifi- 
cation can provide adequate protection. Factors 8 and 9, although 
not explicitly addressed here, will require compartmented infor- 
mation. Each of these factors is discussed briefly below: 


Orbiter Avionics Software Integration Study: Analysis of 
Orbiter Systems to Meet MASE Requirements RES 78-l11- 1, TBM Federal 


Systems Div, Houston, TX, Apr 
' 42 
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TABLE 10 


CHARACTERISTICS OF STS OPERATIONS WHICH TEND TOWARD REQUIRING COMPARTMENTED SECURITY 


When mission, payload, capability and modus operandi of 
national programs is revealed 


When payload operations require extensive coordination 
with STS flight control 


When STS on-board computers support NRP payloads 
When non-nominal payload conditions occur (Payload Specialists) 


When basic Orbiter data is mission, capability, identity or 


modus operandi revealing 


When payload data is available through the Orbiter 


When general and special crew training procedures and equipment 
contain indicators of the mission or operations 


When the STS and crew are directly involved in crisis support, 
compartmented operations or military support 


When the STS and crew are involved in space defense operations 


Past experience suggests there are other reasons not yet discovered 


: 
- Pk ey 4 
° a yin BYERIAN 


contre = 


TOP-SECRET 


43 


0 
ig. Release, 2017/02/27 0509478 


Approved for Release: 2017/02/27 C05094780 


1. MISSION/PAYLOAD IDENTIFY/CAPABILITY/MODUS OPERANDI 
REVEALING DATA ————”—“‘“‘“‘“‘“‘CS.....COVVUU 


Information revealing the above must be appropriately pro- 
tected. Certain information which directly reveals the above for 
a specific NRP program is compartmented. Other information 
less directly revealing may nonetheless be classified because 
it is an indicator which combined with other information may 
reveal the above. In each case, specific tradeoffs are made 
considering security risk, cost of protection, operational factors, 
etc. Wherever this information is contained, it must be protected 
appropriately; e.g. software,.people, data bases, displays, voice 
comm, Simulators, rehearsals, hardware, classrooms, etc. 


POTENTIAL USERS ALL NRP PROGRAMS 
AREAS AFFECTED TRAINING 


‘FLIGHT CONTROL ROOM (FCR) 
. MULTI-PUFPOSE SUPPORT ROOM (MPSR) 
COMPUTERS 
DISPLAYS 
SIMULATORS : 
SGFTWARE DEVELOPMENT LABORATORY (SDL) 
DATA BASES & FILES 
DOCUMENTATION 7 


2. WHEN PAYLOAD OPERATIONS REQUIRE EXTENSIVE COORDINATION/ 
INTERACTION WITH STS FLIGHT CONTROL 


When 'NRP payload operations, rendezvous, retrieval and servicing 
activities, controlled from the DOD POCC reqiire very frequent and 
extensive coordination and interaction with the MCC controlling: the 
SSV, then it becomes imperative that the MCC FCR be fully capable of . 
compartmented discussions and exchanges with the DOD POCC. Compart- 
mented support in real-time or near real-time for the STS could be 


critical to mission success. Coordination between the FCR and POCC 
is enhanced if they can communicate at the compartmented level on 
compartmented programs. When coordination between the FCR and POCC 
is minimal or on a relaxed timeline, the need for a compartmented 
FCR and associated MPSR and flight support is decreased. 


POTENTIAL USERS Palletized Payloads; Retrieval, 
Repair & Service Operations 
AREAS AFFECTED FCR 
? MPSR 
DISPLAYS 
VOICE 


. TELEMETRY (LM) 


once Wis BYEMAN 
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3. USE OF STS ON-BOARD COMPUTERS FOR NRP-PAYLOAD SUPPORT 


In the future, payloads will take advantage of the capabili- 
ties of the STS on-board computers to enhance the flexibility and 
power of R&D experiments, payload operations, and troubleshooting. 
The STS Orbiter computers are accessible through the Mission Con- 
trol Center. Hence, all ‘their data is available throughout the 
MCC. This data could be compartmented data. If so, compartmented 
security throughout the MCC would be required for protection of 
downlinked telemetry, displays and command generation. 


POTENTIAL USERS R&D experiments 
Troubleshooting of all payloads 





AREAS AFFECTED TLM Processor 
Software Dev Lab (command generation 
FCR 
Displays 







4, WHEN NON-NOMINAL PAYLOAD CONDITIONS OCCUR 


When non-nominal conditions are encountered with any NRP 
payload, the payload specialist and other crewmembers will 
troubleshoot the problem and attempt repairs. Coordination, 
discussion and specific supplemental data (to include text and 
graphics) may need to be passed between the crew, the POCC and 
probably the FCR. In the future it is probable that TV pictures 
will be transmitted to the POCC and MCC to aid ground experts 
in troubleshooting the problem with the crew. If the problem goes 
beyond "normal" troubleshooting procedures, compartmented infor- 
mation would probably need to be exchanged. Even though links 
are encrypted, the protection of the compartmented data within 
MCC would be necessary. An alternative approach would be double 
encrypt all data (compartmented voice and data) so as to keep the 
MCC completely out of the compartmented troubleshooting loop. 
This is probably unacceptable from a mission control standpoint. 


POTENTIAL USERS ~ All NRe programs for Troubleshooting 


AREAS AFFECTED Voice (Comm crew-ground) 
Text & Graphics 
Displays (Video & Console) 
FCR (VOICE) 
DOD POCC (Compartmented Security 
already provided) | 
{ 
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5. WHEN BASIC ORBITER DATA IS MISSION/CAPABILITY/IDENTITY/ 
OR MODUS OPERANDI REVEALING _ . 


When NRP payloads particularly those which use the Orbiter 
as a mission platform may find that Orbiter data available in 
the SSV downlinked TLM is itself mission revealing. Examples 
include characteristic power drain, program - specific maneuvers, 
and precise attitude stabilization which are available in tele- 
metry or the state vector. In the current JSC baseline for DOD 
operations, this information is intended to be protected at the 
DOD Secret level, but some NRP programs may require a higher 
classification. 


POTENTIAL USERS Any Payload requiring precision 
pointing 


AREAS AFFECTED TLM Processing Computers 
Computers 
Displays 
FCR 
Network Comm Data Quality 
Monitoring 
MPSR 


6. WHEN PAYLOAD DATA IS AVAILABLE THROUGH THE ORBITER 


This situation is not normally a security problem for DOD 
payloads whose data is encrypted before passing to the STS 
payload data interleaver for encryption again before down- 
linking. In this case payload data after its first decryption 
at the MCC remains encrypted and is passed through to the DOD 
pocc. If a payload did not provide its own encryption or if 
the Payload Specialist's voice is not passed through the pay- 
load's encryption; compartmented information could be present at 
the MCC after decryption. 


POTENTIAL USERS All Payload Specialist Voice 
None presently for Payload Data 
AREAS AFFECTED TLM Computer 
Displays 
TLM Recorders 
FCR 
MPSR 
BANOLE VIA BYEHAR 
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‘7, WHEN GENERAL AND SPECIAL CREW TRAINING PROCEDURES AND 
EQUIPMENT CONTAIN INDICATORS OF THE MISSION OR OPERATIONS 


Crewmembers, especially Payload Specialists, will require 
facilities where procedures, techniques, man-machine inter- 
faces, timelines, troubleshooting methods, etc., can be 
developed and verified for each NRP payload. The full range 
of contingency payload conditions and payload/Orbiter interfaces 
must be explored and rehearsed by the crew before flight readi- 
ness can be certified. ‘Crews must train with the real hardware 
and participate in full-up simulations involving payload tasking 
and control activities and generation of real or high fidelity 
payload data. To do less is to fail to exploit the crew 
capabilities, provide improper or misleading training or readi- 
ness assessments, and potentially jeopardize the mission. 


NEED FOR SECURITY PROTECTION 


In this final section we provide seyeral examples of 
sensitive NRP payload data and operating procedures. 


Sensitive program information must be protected far ahead 
of the launch date for a particular system. It has been shown 
that knowledge of the mass properties of a satellite, useage 
schedule for expendables, etc., can be used to derive an accu- 
rate physical description. This information, together with 
actual or estimated deployment parameters permits assessments 
of the satellite's performance and mission. The referenced 
report concludes that the high correlation to mission type 
makes payload mass properties highly revealing. 


Knowledge of antenna diameter and orbital parameters 
alone permits estimates of the azimuthal resolution of an 
orbiting radar. Advanced knowledge of capability enables an 
adversary time to develop strategy and countermeasures to 
defeat or exploit the systems. The time required to conceive 
and implement camouflage, cover and deception programs is 
often times less than we require to develop, test and field an 
operational space-based synthetic aperture radar for intelli- 
gence collection.. 


H 


Visual data on NRP satellites must be protected because it 
permits estimation of key parameters, ‘such: as antenna size and 
frequency, both key parameters in system gain calculations. 
When combined with orbital parameters and estimates of receiver 


Mass Properties Correlation, BIF-107W-42003-77, 13 Oct 77 
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_ sensitivity, the minimum signal strength collectible by the 
system can be judged. Such knowledge.could enable an 
adversary to design his telemetry transmitters for low power 
operation to preclude effective collection of test range 
data on new missile systems. 


Knowledge of physical properties or visual pictures of a 
satellite allows estimation of frequency coverage. This 
knowledge permits an adversary to plan emission control pro- 
cedures for use when the satellite is in view. 


General and special crew training and procedures can be 
very clear indicators of satellite mission and operation. The 
crew must train on realistic simulators, with the actual hard- 
ware, and interface with operational organizations. The 
mission-specific training hardware/software and patterns of 
crewmember activities require protection since they reveal not 
only mission but are schedule indicators since typical Shuttle 
activity planning timelines have been published openly. 


Crew activity timelines, even devoid of mission specific 
details, may be combined with externally derived Orbiter posi- 
tion data from space tracking sensors to make“estimates of 
areas of interest over which U.S. payloads are operating and 
thereby indicate tasking patterns or call attention to an 
overlooked area. Further, Orbiter attitude and positioning in 
conjunction with certain Payload Specialist operations or 
Orbiter telemetry data; e.g., power drain could indicate a 
photoreconnaissance mission. 


Orbital parameters and launch times of NRP payloads require 
Protection far in advance of launch dates. Some missions by 
their very nature require specific parameters (e.g. sun angle, 
inclination, period orbital altitude) which over a period of time 
become characteristic signatures of those missions. Surprise can 
and has paid big dividends in collections. The early intelli- 
gence take before the adversary has time to sort out the mission 
of the newly-launched payload and implement CCD activity is 
Usually the most valuable. Similarly, knowledge of orbital 
Parameters and even gross schedule information enables corre- 
lation with past activity and divulges replenishment strategy. 


Tight effective security permits us to capitalize on 


Surprise, take advantage of cover opportunities provided by 


Similar missions, and delay, confuse and misdirect enemy 
Countermeasures. 
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STS FLIGHT OPERATIONS DEFINITIONS 
- FLIGHT PLANNING 
~ FLIGHT READINESS 


- FLIGHT CONTROL 


NOTICE REGARDING SECURITY 
MARKING OF THIS APPENDIX 


Information in this Attachment has been extracted ° 

from the unclassified docuthent Mission Operations 
F Plan for the DOD Space Transportation System Pro- 

gram, SAMSO-LV-0020, dated January 1979. However, 


these extracts were annotated to assist NRP pro- 
gram offices (and subsequent readers) in making 
assessments of the security levels required to 
carry out various Shuttle flight planning, readi- 
ness and control activities. Any annotations and 
comments involving the terms NRP, NRO, or BYEMAN 


cause the page to be marked TOP SECRET/BYEMAN or 
SECRET/BYEMAN . 






* 
Mission Operations Plan for the DOD Space Transporta- 
tion System Program, SAMSO~-LV-0020, Jan 79 
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The following information has been extracted from the 
Mission Operations Plan for the DOD Space Transportation Program, 
. SAMSO-LV-0020, Jan 1979, a comprehensive roadmap and description 
of activities expected to be involved in the flight planning, 
readiness and control of DOD missions using the Shuttle. These 
extracts were prepared to give the program offices (and subsequent 
readers) insight into each of the activities involved so they may 
begin to appreciate workload implications, agencies involved, and 
security concerns which arise in each. 


NOTE: The Mission Operations Plan (SAMSO-LV-0020) as base- 
lined assumes JSC as the Shuttle Planning and Control Center so 
activities and events presented typify that flow. The reader 
should keep this in mind when reviewing the following extracts. 
However, nearly all the activity presented is generic and must 
be accomplished somewhere, i.e., at DOD, contractor, or NASA 
facilities as may be determined. 


In the following extracts, the symbol "oo" is occasionally 
used to flag attention to those activities considered likely to 
involve compartmented information. 


FLIGHT PLANNING FUNCTIONS 
Flight Planning Functions include: < 


1. Flight feasibility analysis 

2. Payload flight support requirements development 
3. Utilization planning (of thé STS) 

4. STS flight design 

5. Upper stage flight design 

6. Flight crew activity planning 


Each function is described in greater detail below so assessments 
of the security level necessary for each can be made: 


1.1 The Flight Feasibility Analysis function performs the planning, 
technical analyses and interagency coordination to eliminate any 
serious questions about the capability of the STS to support user 
flight requirements. It begins up to four years prior to launch 

and ends with completion of the spacecraft preliminary design review. 
Program data is revealed throughout the supporting agency structure 
(e.g., to SAMSO/LV, AFSCF, launch bases, and NASA) as necessary agree- 
ments and documentation to establish program support. Data included 
is: 


UNCLASSIFIED 
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Spacecraft Data and, Flight Objectives, Schedules 
Interface Requirements Documents 

STS Flight Requirements, Constraints and Assumptions 
Design Reference Missions 

Contingency Analysis Guide 

Spacecraft PDR Data 

Mission Interface Verification Plan 


Some key outputs of this function are: 
An Interface Requirements Document including: 


Ground Operations : 

Flight Operations 

Spacecraft Subsystems 
Security 
Environment 


A Mission Interface Verification Plan 
A'Flight Feasibility Review and Spacecraft PDR 


STS Mission Plan, including requirements, constraints and 
assumptions like: 


Launch Windows 
Orbit Parameters 
On-orbit Operations 
Contingencies 
Launch on Demand 
Crew Activities 


1.2 Payload Flight Support Requirements Document. This function 
prepares requirements for Support from DOD and NASA organizations 
that perform flight operations; agreements for flight operations | 
integration (Payload Integration Plan); agreements for NASA flight 
operations support; agreements for AFSCF flight operations support. 
Satisfaction of these requirements is determined through: 


Flight Operations Review (FOR) (NASA) 
Independent Readiness Review (IRR) (DOD) 
Flight Readiness Reviews (FRR) (NASA) 


The Flight Operations Section of the Payload Integration Plan 
includes: 


Mission Operations 
Preliminary Mission Scenario 
Orbital Requirements and Payload Control 


Parameters 
Operational Requirements and Constraints 
Prelaunch 
UNCLASS IFIED 
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Ascent 

On-orbit 

Entry 

Post Landing 
Flight Operations 
Flight Design (b)(1) 

Crew Activity Planning (b)(3) 10 USC + 424 
Training 

Flight Operations Control 

Command and Control Support 


ean eee eae Sa 
ee renner eemrpeneet oon 


The seven PIP Annexes below are prepared. They say what SAMSO, 
the SPO and the NASA (JSC) will do and what the SPOs require- 
ments are: 


oo «Flight Planning - covers flight design data, crew activi- 
ties. This could be payload and mission-revealing: 


oo Flight Operations Support - covers payload decision points, 


communications and data management, natural environment 
Support, ground controlled payload operation and procedures. 


oo Training - this provides a schedule and description of 
payload unique training activities and facility needs. 


oo Command & Data - defines specific payload commands and 
measurements for any transmissions via Orbiter data links. 





NOTE: If you use to contact your P/L while on the STS, 
you need this; if you only use the STC, you don't. 
’ POCC Reguirements - for DOD programs the STC is the POCC. 











66 Orbiter Crew Compartment - this includes detailed descrip- 
tions of payload items stowed in the crew compartment -- \ 
Will your Payload Specialist have troubleshooting tools or 
special EVA gear? This Section also defines nomenclature of 
payload assigned controls and displays in the aft flight deck. 
deck. 


oo Payload Data Package - this Annex requires payload programs 
' to provide detailed payload characteristics, such as their 
sequence of mass properties, configuration drawings of major 
elements, RF transmitter characteristics, and payload func- 
tional data. s 


1.3 Utilization Planning of the STS 
This function performs the technical analyses, planning and 
coordination necessary to determine a compatible grouping of pay- 


loads, to obtain flight assignment, and to participate in the 
Cargo Integration Review. 


UNCLASS IFIED 
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me geven PIP Annexes below are prepared. They say what SAMSO, 
age SPO and the NASA (JSC) will do and what the SPOs require-. 
wees are: 


oo Flight Planning - covers flight design data, crew activi- 
ties. This could be payload and mission-revealing: 


_ @0 Flight Operations Support - covers payload decision points, 
; communications and data management, natural environment 


support, ground controlled payload operation: and procedures. 


eo Training - this provides a schedule and description of 
payload unique training activities and facility needs. 


‘oo Command & Data - defines specific payload commands and 
measurements for any transmissions via Orbiter data links. 


: (b)(1) 
If you we ite contact your P/L while(b)(3) 10 USC + 424 
you need this; if you,only use the STC, you don't. 
POCC Requirements ~ for DOD programs the STC is the POCC. 





Orbiter Crew Compartment - this includes detailed descrip- 
tions of payload items stowed in the crew compartment -= 
Will your Payload Specialist have troubleshooting tools or 
Special EVA gear? This Section also defines nomenclature of 


eo assigned controls and displays in the aft flight deck. 
eck. 


Payload Data Package - this Annex requires payload programs 

to provide détailed payload characteristics, such as their 

sequence of mass properties, configuration drawings of major 

elements, RF transmitter characteristics, and payload func- 

tional data. 

3 Gtilization Planning of the STS 

digas cmetion performs the technical analyses, planning and 
“etion necessary to determine a compatible grouping of pay- 


Set ; ; ie 
,-0 Obtain flight assignment, and to participate in the 
“segration Review. 
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If your payload requires a dedicated STS flight, this step is 
no problem -- we simply reserve a flight for your payload. 


oo If you require less than the full bay, you will have to 
reveal your spacecraft parameters to permit ride-sharing 
studies -- parameters like weight, volume, size, moments, 
power requirements, contamination, deployment sequences, 
Operations sequences, electromagnetic capability, thermal 
needs, launch windows, sun angles, orbit parameters, etc. 
Any other ride-share candidate must likewise share such 
data with you. - 


oo DOD plans to do its own cargo integration using its Pay- 
load Integration Contractor. However, if NRP cargo and 
any non-DOD cargo such as NASA or commercial cargo are 
considered for ride-sharing, procedures will have to be 
developed to protect NRP information. 


1.4 STS Flight Design 

In this function, SSV flight designs to satisfy cargo require- 
ments are developed. The SSV flight design includes the trajectory, 
ground tracks, attitude and pointing timelines, and consumables 
useage profiles for the SSV plus the relative motion of free-flyer 
spacecraft while in the vicinity of the Orbiter. 


Function Inputs: 


1. STS Preliminary Mission Plan: Spacecraft Feasibility, 
Revision 1. 
2. PDR Trade Studies (Flight Operations) 
3. PDR Minutes 
4. Flight Requirements (IRD or ICD) 
5. Upper Stage Preliminary Flight Design 
6. Preliminary System Analyses Results 
7. CDR Minutes 
8. Mission Interface Verification Plan 
9. Payload Mixing Report 
10. FID (Flight Operations) 
ll. Upper Stage Conceptual Flight Design 
12. Summary Payload Crew Activity Plan 
13. Summary Crew Activity Plan 
14. PIP Annex for Flight Planning 
15. Upper Stage Operational Flight Design 
16. Detailed Payload Crew Activity Plan 
17. Detailed Crew Activity Plan 
18. LOD Plan 
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Function Outputs: “a 


1. STS Preliminary Mission Plan: Payload (Basic, 
Revision 1 and Revision 2) 

2. Data for PIP Annexes 

3. STS Preliminary Mission Plan: Cargo 

4. Conceptual Mission Plan (Basic and Revision 1) 

5. SSV Conceptual Flight Design 

6. Operational “Mission Plan 

7. SSV Operational Flight Design 


1.5 Upper Stage Flight Design (Applicable to some Programs) 


If an upper stage has been assigned to the spacecraft, vehicle- 
specific data can be used in this design. The flight design also 
includes variation of the parametrics in order to determine a range 
Of operation for the flight. 


oo The data involved in this function is clearly program 
specific 


1.6. Flight Crew Activity Planning 


This function develops crew procedures and crew activity 
timelines to be performed by the flight crew during flight. This 


function covers crew activity planning after the cargo is baselined 


at the CIR. Prior to this period, crew activity planning is per- 
formed as part of the STS flight planning for the payload and cargo 
using standardized crew activity profiles or timelines rather than 
detailed analyses. 


The crew activity plan defines how the flight will be flown 
by the crew. It contains the schedule of crew activities and 
relates them to ground support activities. Steps in crew activity 
planning include: 


oo Developing an integrated summary crew activity plan 
prior to the FOR. 


oo Developing execute data (crew procedures, reference data, 
time references, etc.). 


NOTE: The crew planning includes activities to be done by their 
flight operations support personnel on the ground. 


FLIGHT READINESS FUNCTIONS 
The Flight Readiness element is composed of functions 


related to the preparation and training required for a flight. 
These functions are: 
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- Flight Data File Preparaticn 

SSV On-board Digital Data Load Preparation 

Upper Stage On-board Digital Data Load Preparation 
Flight Crew Training 

SSV Flight Operations Support Personnel Training 
Payload Flight Operations Support Personnel Training 
- Integration Rehearsals/Simulations 


iJ e 


NOOB Wb 
. 


The Flight Data File (FDF) is the total onboard set of 
documentation and other operational aides for the flight crew. 


The SSV/FDF contains components that will be used for STS 
operations including payload activation, deployment and deacti- 
vation. 


The Payload FDF contains components required for the operation 
of a payload itself during the on-orbit phase of SSV operations. 


‘For some SAFSP payloads, where the deployment is straightforward 


and similar to standard DOD payloads, a separate payload FDF may 
not be required. In these cases, most probably a DOD Secret/ 
mission specific input would be generated for the.FDF file by 
SAMSO/LV. In some cases however, the activation/deactivation 

and deployment sequences may be complex or the flight crew may have 
some other intervening non-related function to accomplish during 
the middle of a particular deployment, or a reiterative unique 
process may be required for deployment. Then a separate/peculiar 
FDF would be required. This could be conceivably” generated by 
SAMSO/LV as DOD/SECRET or by SAFSP as BYEMAN depending on the 
degree to which the file would be mission revealing. 


The typical components within the FDF are as follows: 


© Orbit Operations Checklist 
oo Rendezous Book 
o Deploy Checklist 
Oo Retrieve Checklist 
oo EVA Checklist 
oo Payload Checklist 
oo Payload Schematics ; 
oo Payload Malfunction Procedures 
oo Payload Crew Activity Plan 
oo Payload Operations Summary 
oo Payload Operations Reference Data 
Oo Payload Operations Cue Card 
o Star Charts 


The components indicated by."o0o" are items most likely to 
require "BYEMAN" security. 
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The SSV On-board Digital Data Load (ODDL) preparation con- 
Sists of all data loaded into two (2) redundant mass memory 
units of the SSV data processing system. It consists of computer 
programs (code) and the flight dependent data (I-loads) that 
specify a particular flight. The mass memory software contains 
the following software elements: 


Primary Avionics Software System (PASS) 
Pass Inbedded Software 

Backup Flight Software 

GPC System Software Loader/Self Test Program 
(SSL/STP) 

Display Electronics Units (DEU) 

Space Shuttle Main Engine (SSME) 

oo Display Text and Graphics 

oo Test Control Supervisor Sequences 

oo Payload Data Interleaves (PDI) 

oo Telemetry Format Loads (TFL) 


0000 


000 


Flight specific requirements, for both code and data, are 
implemented by NASA into a baseline SSV MMU by either a patching 
process. or completely rebuild with classified I data. Any 
necessary on-pad changes are accomplished by patching process. 
NASA has the responsibility for generating the SSV ODDL and 
SAMSO/LVO for reviewing prior to certification. The elements 
indicated with “oo" may contain specific payload data that is 
Mission revealing. 


NOTE: Present plans are to use the STC for all DOD payload 
commanding and checkout. The payload is interrogated 
directly from the SCF ground stations. However, you should 
recognize that Payload Specialists will accompany all NRP 
payloads for troubleshooting or payload operation. The 
Orbiter computer (processor and mass memory) and payload 
interrogation equipment will likely be used since they are 
standard equipment. Program specific, possibly BYEMAN data, 
will be resident in the SSV computer -- hence, accessible to 
the ground. As an alternative, each NRP program would have 
to provide their own space qualified hardware for this task. 


The Upper Stage On~board Digital Data (ODDL) Load consists 
of the total contents (program code and mission data values) of 
the upper stage avionics memory prior to any processing by the 
upper stage flight computer. The preparation responsibility for 
the upper stage ODDL for DOD mission belongs to SAMSO/LV. For 
SAFSP missions, the data within the Uppes Stage ODDL is con- 
Sidered BYEMAN. 
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Flight crew training encompasses the classroom and simula- 
tion traiming of the STS flight crew (Commander, Pilot and Mission 
Specialist). The planning, developing, managing and operating 
functions for the training programs and supporting facilities 
includes the analysis of operator tasks, preparing training aid 
materials, defining facility requirements, and the scheduling of 
execution of training exercises for the full crew complement 
(primary and backup) for a specific flight. 


For a given flight phase or sequence, the training operations 
are scheduled so that the flight crews and appropriate SSV flight 
operations support personnel together receive workbook lessons 
first, then simulator training, integrated rehearsals/simulations, . 
ete. Due to different training and security requirements, the 
Pilot, Commander, Mission Specialist and Payload Specialist, plus 
appropriate flight operations support personnel, may undergo 
different flight phase training at the same time. In general, 
common training requirements will be accommodated in conjunction 
with the generalized NASA training program. Flight specific 
training for the SSV flight crew, payload flight crew, and SSV 
FOSP that emphasizes Orbiter payload interactions instead of 
detailed payload operations will require a DOD Secret or a Top 
Secret compartmented environment depending.on the extent of 
interaction and the amount of information disclosed that is 
directly mission revealing. This training would normally acquaint 
the flight crews and SSV FOSP to payload specific requirements 
and constraints. It will emphasize flight unique configurations and 
requirements for stowage, TV and photography, and crew system sub- 
systems; altitude and translation maneuvers; deployment; ascent, 
abort, deorbit, entry and prelaunch operations; planning techniques; 
flight data organization; and EVA operations, if required. The 
Shuttle Mission Simulator (SMS) presents payload flight dynamics 
and systems parameters in a real-time environment, is utilized by 
the SSV and payload flight crew for flight specific training 
rehearsals/simulations. The SMS security environment required for 
SAFSP programs will vary from DOD Secret, Top Secret SI/TK, to a 
BYEMAN environment. While ascent and reentry simulations are less 
sensitive (they do require your payload mass properties, moments, 
etc.), the on-orbit simulation may need to be compartmented 
depending upon what is revealed by payload visual access through 
Simulated views, payload operation or deployment activities, etc. 


Integrated rehearsals/simulations are the final level of 
SSV flight dependent training.. All relevant flight elements, 


including SSV and payload flight crew, SSV flight operations 

Support teams and communication and data networks. These 
‘rehearsals/simulations verify procedures and timelines which involve 
the members of the STS flight crew, payload flight crew, and the 

SSV FOSP, and demonstrate crew and FOSP efficiency. One or more 
flight crew perform SSV flight operations from the simulator and 

the SSV flight operations support personnel (FOSP) participate 
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from their assigned c. .sole positioris. The commuuications network 
is simulated. Normal and alternate flight simulations scenarios 
will probably be accommodated with a "DOD Secret" environment. 
However, contingency scenarios especially with regard to a specific 
payload; i.e., deployment, EVA, or retrieval could necessitate a 
“higher level of security. ; 


FLIGHT CONTROL FUNCTIONS 


The Flight Control element is composed of functions related 
to the prelaunch, flight, and post-flight operations for the SSV 
and payload. 


1. SSV Flight Operations Planning - covers the tasks 
which ensure that the Orbiter Mission Control Center (MCC) is 


properly configured to support flight operations. In particular, 
this function will: 


a. Define and implement flight peculiar MCC modifi- 
cations 


b. Configure MCC consoles and displays 

c. Configure the communications and tracking network 
d. Prepare Operations Documentation 

e. Update flight rules 


£. Define and support validation of nominal and 
contingency flight support procedures and techniques 


‘g. Define and validate MCC external and internal 
interface 


h. Prepare and validate operations data 


i. Configure the operations data base. 


* cbs Payload Flight Operations Planning - covers the tasks 
which ensure that the Payload Operations Control Center (POCC) is 


properly configured to support payload mission operations. The 
Pocc is assumed to be located at the AFSCF and does not include 
payload operations outside the -vicinity of the STS. This function 
involves the following tasks: 


UTR 





é 


Establish Mission Control force 

Prepare DOD STS Orbital Support Plan Annex 
Procure new syStems to support payload operations 
Prepare Payload Test Program Planning Schedule 


eUPES prea c ym eo 


(cont'd on next page) 
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Prepare STS Test Operations Order Annex E 
Prepare Cargo Element Orbital Operations Handbook 
Prepare Payload Orbital Test Plan 

Prepare Payload Flight Support Plan 

Prepare Payload Telemetry Modes 

Generate Payload Command Messages 

Schedule Network Support for Payload Operations 
Prepare Pass Plans 


SSV Prelaunch Operations - includes all activities 
eens with countdown and concluding at Solid Rocket Booster 
(SRB) ignition. During prelaunch operations the SSV flight 
operations support personnel are performing the following 
activities: 


a. Verifying the SSV and payloads configuration and 
status 


‘b. Monitoring consumables loading 


¢. Verifying internal, POCC (STC), and tracking 
network communications and operational support status. 


d. Monitoring terminal countdown 
e. Verifying landing sites operational status. 


-£. Providing telemetry and command communication 


g. Configuring in-house data processing systems 


h. Updating and verifying SSV mass properties 


4, Payload Prelaunch Operations - includes those activi- 


ties performed by the POCC which are necessary to ensure the 
operational readiness of the AFSCF support systems and to con- 
firm the payload health and status. The Remote Vehicle Checkout 
Facility (RVCF) at KSC supports the transmission of command and 
telemetry data between the launch site and the STC. A similar 
function is performed at Vandenberg AFB. Activities included in 
this: function include: 


a. Payload prelaunch checkout 
b. Payload launch countdown support 


The security level required for this function is dependent upon 
how much payload command and telemetry data is classified; if 
classified, is it securely transmitted/received? is there a pro- 
gram requirement for or a system weakness that permits access to 
this data by SSV ground support personnel? 
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5. SSV slight Operations Support - includes all 

activities performed’ by the SSV ground support system beginning 
with SRB ignition and ending with crew egress after Orbiter t~ 
landing. These activities include: 

a. Trajectory monitoring and navigation support 

b. SSV systems monitoring and failure detection 

c. Contingency and abort analyses 

d. External Tank (ET) and SRB impact prediction 

e. Real-time flight replanning 

£. Inflight anomaly analysis 

g. Vehicle configuration recommendations 


SSV Flight Operations covers the following general phases: 


Launch Operations ~ SRB ignition through orbit insertion. 
The SSV, MCC activities in support of this phase include: 


a. Predict and identify abort situations 
b. Provide vehicle configuration recommendations 


c. Compute trajectory support data to verify vehicle 


' The use of the on-board computer for payload activities and the 
access of its data to the ground network will be a major detriment in 
establishing the security requirements for this function. 


Orbital Operations - Orbital injection to vehicle reentry 
preparation. During this phase, SSV ground support elements pro- 
vide flight-related communications, systems and trajectory 
monitoring, data retrieval, flight planning, and operations 
resources management. The crew activities included in the Payload 
Operations Support Function (see below) are performed during this 
phase. The interaction of Orbiter and payload support activities, 
interfaces and resources will be decisive in determining security 
requirements. 





_and Landing Operations - Vehicle reentry preparations 
crew egress after Orbiter landing. During this phase, the 
crew is preparing the Orbiter and its payloads for reentry. The 

ground support elements provide the crew with trajectory, meteoro- 


‘logical, and support facilities status information relative to 


primary, secondary, and contingency landing sites. The ground 
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support elements provide the following: 


a. Weather updates and ground navigation aid status 


b. Systems monitoring and failure detection 
c. Verify landing site navigation aid updates 


d. Assist crew in performing manual reentry and 
landing : 


6. Payload Flight Operations Support - consists of all 
activities performed by the POCC supporting the payload mission 
during the period from SRB ignition through crew egress. These 
activities may actually conclude with deployment for freeflyer 
payloads. These activities include:? 


a. Mission direction 

b. Health and status monitoring 

cs Tracking and telemetry processing 

d.. Orbit determination 

e. Mission data receipt and descrimination 


Payload Flight Operations covers the same phases as SSV Flight 
Operations. e 


Launch Operations - The POCC monitors the health and status 
of the payload if this information is handwired across the inter- 
face to the Orbiter avionics. The downlink data is received via 
either: (1) Orbiter FM data to MILA (at KSC), to the RVCF, to 
the STC, to the POCC, or (2) interleaved Orbiter/payload telemetry 
data to GSTDN (Ground Spaceflight Tracking and Data Network) to 
Goddard, to JSC, to the STC, to the POCC. 


On-Orbit Operations - After injection, a number of different 
payload related options can be performed. These include: 


a. Pre-deployment -- all Orbiter and payload preparations 
required prior to exposing the payload to the space environment 


b. Checkout and deployment of freeflyer -- all Orbiter 
and payload activities associated with release of the payload. 
During this period, the SSV crew or the POCC will perform payload 
checkout, coordinate activities with the SSV MCC, determine Go/No-Go 
decisions for deployment, and execute the payload deployment sequence. 
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c. Post Deployme - After payload release, 1e crew will 
reconfigure the Orbiter and maneuver it away from the payload. 
The POCC continues to monitor health and status via its own link 
or through the Orbiter avionics relay capability. Upon completion 
of the last deployment related activity, the POCC assumes total 
control of the payload. 


d. Pallet Checkout and Operation - The Payload Specialist 
crew and/or the POCC will perform all activities associated with 
the checkout and on-orbit operation of the payload. This can be 
accomplished through payload dedicated avionics (Orbiter autonomous), 
through the Orbiter avionics (telemetry and command systems), or by 
the on-board data processing capabilities (computer and avionics). 
The security requirements for this function will be dictated by the 
degree to which the SSV and payload flight and ground systems are 
physically and operationally integrated. 


e. Repair/Service/Retrieval of a Free-flyer -- The 
rendevous and mating activities associated to perform a repair/ 
service/retrieval mission will require greater crew involvement and 
increased use of Orbiter flight and/or ground support services. 

The potential for EVA is also greater. These activities will be 
closely monitored by the ground support teams and will very possibly 
require BYEMAN communication and data interfaces. 


£. Reentry and Landing Operations - - The crew and/or the 
POCC will prepare the payload for reentry and landing. 


7. SSV Operations Postflight Analysis -- This function 
analyzes the SSV mission operations support, develops means and 
ways to improve this support, provides raw and processed SSV data 
for performance and operations evaluations. The activities involved 
include: 
a. Assimilate and distribute SSV anemaly reports. 


: b. Process and reduce NASCOM communications and tracking 
data 


c. Disseminate telemetry data to users 


d. Perform flight crew and flight operations support 
debriefing 


e. Perform orbit and trajectory reconstruction 
£. Evaluate overall flight performance 


g. Update simulation models and data base 
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: 8. Payload Operations Postflight Analysis -- This function 
; analyzes the effectiveness of the payload flight operations 
Support and develops ways and means to improve it. This function 
does not include payload operations outside the vicinity of the 
} STS. In particular, it evaluates and documents the effectiveness 
i of the payload operations in the performance of: 






Flight Feasibility Analysis 

Payload Flight Support Requirements Development 
Upper Stage Flight Design 

Upper Stage ODDL Preparation 

Payload FOSP Trdining 

Payload Flight Operations Planning 

Payload Prelaunch Operations 

Payload Flight Operations Support 


aoo0o0o00oo0o00 


The purpose of this analysis is to maximize the effectiveness of 


the flight operations support by isolating and eliminating 
problem areas. 
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~20t. Office of Management and Budoet Study Report 
“=. SRMSO/LVO (Col Boyland) 


1. Reference LVO letter, this subject, 25 April 1979. (Cy Atch.) 


2. Forwarded herewith is.the data requested in your 


letter. It represents a preliminary estimate of our 
recuirements at this“vime. 


~@OHN E. Atch 
/saier General, USAF SAFSP Shuttle Requirements — 
i; “~% Director Rpt (Preliminary) 10 May 79 (S) 
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SECURITY NOTICE 
THIS ATTACHMENT IS DOD SECRET 


This Attachment is a copy of SAFSP's DOD SECRET report 
which forwarded Shuttle workload and security require- 
Ments to SAMSO. SAMSO consolidated these with other 
DOD requirements and forwarded overall requirements 
package to: 


a. HQ USAF for inclusion in Annex C of the Shuttle 
Mission Operations Task Force Evaluation, itself an 

Attachment to the Mission Element Needs Statement for a 
DOD Shuttle Operations Planning Center. 







b. NASA/JSC for use by the SAMSO/NASA working 
group analyzing Shuttle control options. 






Tables in this Attachment are referred to in the work- 
load and security sections of the main report and are 
therefore provided here for reference. 


If inclosures.are withdrawn (or not 
attached the classification of this 


correspondence will be UNCLASSIFIED. 


ANNEX D 


SEERA ATTACHMENT 2 
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— SEGRE 


STS WORKLOAD REQUIREMENTS 


Workload categories included are: 


© Payload delivery of free-flyers 








o Payload piatform/pallets 





© Retrieval 1 

(b)(1) 
o Repair and service (b)(3) 10 USC + 424 
o On-orbit construction 


Programs included in Rev 8 of the STS Mission Model are 
included in Table l. 


The scheduled STS Workload (Table 1) reflects the May 


1979 program baselines through 1985 and its outyear 


implications through 1991. Projections through 1995 
continue patterns established in prior years. 











In Table 1 the total number of Delivery 
cannot be directly equated to total number of Orbiter 
flights because of ride sharing, and because multiple 
missions may be accomplished on the same STS flight. 
The compatibility of multiple mission support on any 
STS flight can only be assessed on a_case=-by-case basis 
and cannot be determined at this time. 





Table 2 presents the potential contingency workload 
forecast for those programs included in Rev 8 of the 
STS Mission Model (Table 1). The present Rev 8 does 
not include any contingency workload in response to 
crisis situations or unforeseen failures. 


Table 3 presents workload not reflected in Rev 8 of the 
STS Mission Model. It represents potential R&D STS work- 
load for advanced future systems, experimental system 
brassboard tests, subsystem tests, and component tests. 
While a few R&D efforts require dedicated missions, most 
R&D payloads are small ride. share candidates. Component 
tests for example are typically 250 pounds, five cubic 
feet, sealed cans. 


Table 4 is a summary of the scheduled, contingency, and 
R&D workloads, and reflects an estimated range of potentia: 
STS support missions. 
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(STS SECURITY REQUIREMENTS 


1. STS mission operations will involve Flight Planning, Flight . 
Readiness and Flight Control activities. While no program has 
yet gone through all the steps which will be involved, a com-: 
prehensive description of tasks and subtasks for each activity 
has recently been published in the MISSION OPERATIONS PLAN FOR 
THE DOD SPACE TRANSPORTATION SYSTEM PROGRAM, SAMSO-LV-0020, 
Jan 1979. These twenty-one element tasks are based on the 
successful pattern developed by NASA for the APOLLO and SKYLAB 
programs. The tasks described in the Mission Operations Plan 
are considered representative of workload to be accomplished 
independent of where the work is actually done. 


2. Based on task descriptions in the Mission Operations Plan, 
assessments were made of the security level required to 
adequately conduct program-specific work on the tasks and sub- 
tasks of each of the twenty-one major activities encompassed 
in Flight Planning, Flight Readiness, and Flight Control. 
Table 5 summarizes the STS security requirements baseline for 
each of the twenty-one activities for each of five workload 
classes. 


3. Because each program has its individual requirements, not 
all elements may be needed. For example, some programs have 
upper stages, others do not. Similarly, within any workload 
category, a range of security level required is shown which 
accommodates the needs of individual programs. Column six of 
Table 5 displays the overall security requirements for each 
activity. ; 
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STS MISSION OPERATIONS ELEMENT 


*FLIGHT PLANNING 


I. 
2. 


3. 
4. 


5. 
6. 


Flight Feasibility Analysis 
Payload Flight Support ’ 
Requirements Development 

STS Utilization Planning (Payload 
Mix, Flight Assignment) 

STS Flight Design 

Upper Stage Flight Design 





























Eee TABLE 5 
STS SECURITY REQUIREMENTS 
WORKLOAD CLASS 
REPAIR OVERALL 
& CONSTRUC- REQUIRE- 
DEPLOY PALLET RETRIEVAL SERVICE TION MENT 

TSC TSC 
S->TSC Tsc 
S->TSC s TSC 
S—>TSC TSC TSC 
N/A=¥TSC N/A->TSC TSC 
S=>TSC TSs¢c Tsc 


Flight Crew Activities Planning 


*PLIGHT READINESS 


1. 
2. 


Flight Data File Preparation 
SSV On-Board Digital Data 
Load Preparation 

Upper Stage On-Board Digital 
Data Load Preparation 

Flight Crew Training 

SSV Flight Operations Support 
Personnel Training 

Payload Flight Operations 
Support Personnel Training 
Integrated Rehearsals and 
Simulations 


*FLIGHT CONTROL 


1. 
2. 


3. 
4. 


SSV Flight Operations Planning 
Payload Flight Operations 
Planning 

SSV Prelaunch Operations 
Payload Prelaunch Operations 
SSV Flight Operations Support _ _ 
(launch, on-orbit, zrecovery) 
Payload Flight Operations 
Support 

SSV Operations Post-Flight 
Analysis 

Payload Operations Post-Flight 
Analysis 





* 

















S-)TSC 
S—>TSC 


TSC 
TS¢c 








N/A->TSC N/A=>TSC 


S$ & TSC 
s 











S & TSC 
TSC 





Ts¢c N/A->TSC 






TSC 


Ref: Mission Operations Plan for the DOD STS Program (SAMSO/LV-0020, Jan 79) 


KEY: $ = DOD SECRET 


TSC = TOP SECRET Compartmented 


N/A = Not Applicable 


—> Indicates Range of Requirement 
& Indicates both security levels are required 


Director, SAFSP 
10 May 1999 
2-301.¢.6 
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